ClickHouse

20.7.3.14

20.5 final

20.6.3 explain

1. 介绍

  1. 俄罗斯Yandex开发。
  2. 列式存储数据库（相较于MySQL等行式存储数据库区别）。
    • 列式存储是指数据在磁盘中以列的方式进行存储。相较之下查询相同列的数据的时候比较快，查询行的数据比较慢，可能需要遍历整张表，但是修改的代价高。列式存储对聚合、计数、求和等操作速度远快于行式存储，更适合进行查询分析的场景。某一列的数据类型是相同的，可以进行数据压缩。
    • 行式存储查询行的数据比较快，但是查询某一列的数据就比较慢，可能要遍历整张表，但是修改的代价低。更适合进行联机修改的场景。
    • 类比成数据结构中的线性表的优缺点。
  3. 用途：在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。
  4. C++编写。
  5. 可以使用SQL语句进行操作。
  6. 引擎分类：合并树（Merge Tree）、日志、接口、其他四大类20多种。
  7. 高吞吐写入能力。采用LSM Tree结构，数据写入是顺序append写，写入后不可更改。数据写入定期后台Compaction，多个段merge sort后顺序写回磁盘。
  8. 数据分区和线程级并行，单条Query就能利用整机所有CPU，吃CPU，对于高qps的查询业务不是强项。
  9. 适合大量数据的宽表场景。
  10. 避免join操作（把右表加载到内存，再和左表匹配）。

2. 安装

  1. 关闭防火墙或者开放端口。

  2. 取消Linux上的文件数及用户最多进程数的限制。

    $ ulimit -a

主要修改的是这两个
open files
max user processes

    $ sudo vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

* 限定域为所有用户
soft软限制，日常状态/hard硬限制，最大上限

$ sudo vim /etc/security/limits.d/20-nproc.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

  3. 重新登录。

  4. 安装依赖。

    sudo yum install -y libtool
sudo yum install -y *unixODBC*

  5. CentOS取消SELINUX

    SE:security enforce.

    $ sudo vim /etc/selinux/config
SELINUX=disabled

  6. 重启。

  7. 安装。

    sudo yum install clickhouse-server clickhouse-client

vim /etc/clickhouse-server/config.xml
# 把 <listen_host>::</listen_host> 的注释打开，让CH支持远程访问。

  8. 重启服务。

3. 数据类型

3.1. 整型

固定长度的整型，包括有符号整型或无符号整型。 整型范围(-2n-1~2n-1-1):
Int8 - [-128 : 127]
Int16 - [-32768 : 32767]
Int32 - [-2147483648 : 2147483647]
Int64 - [-9223372036854775808 : 9223372036854775807]

无符号整型范围(0~2n-1):
UInt8 - [0 : 255]
UInt16 - [0 : 65535]
UInt32 - [0 : 4294967295]
UInt64 - [0 : 18446744073709551615]
使用场景: 个数、数量、也可以存储型 id。


Int8 - byte
Int16 - short
Int32 - int
Int64 - long

3.2. 浮点型

Float32 - float
Float64 – double

浮点型进行计算时可能引起四舍五入的误差。

使用场景：一般数据值比较小，不涉及大量的统计计算，精度要求不高的时候。比如 保存商品的重量。

3.3. 布尔型

没有单独的类型来存储布尔值。可以使用 UInt8 类型，取值限制为 0 或 1。

3.4. Decimal 型

有符号的浮点数，可在加、减和乘法运算过程中保持精度。对于除法，最低有效数字会 被丢弃(不舍入)。

有三种声明:

Decimal32(s)，相当于Decimal(9-s,s)，有效位数为1~9
Decimal64(s)，相当于Decimal(18-s,s)，有效位数为1~18
Decimal128(s)，相当于Decimal(38-s,s)，有效位数为1~38

s 标识小数位 使用场景：一般金额字段、汇率、利率等字段为了保证小数点精度，都使用 Decimal进行存储。

3.5. 字符串

String

字符串可以任意长度的。它可以包含任意的字节集，包含空字节。

FixedString(N)

固定长度 N 的字符串，N 必须是严格的正自然数。当服务端读取长度小于 N 的字符

串时候，通过在字符串末尾添加空字节来达到 N 字节长度。 当服务端读取长度大于 N 的 字符串时候，将返回错误消息。

使用场景：称、文字描述、字符型编码。 固定长度的可以保存一些定长的内容，比 如一些编码，性别等但是考虑到一定的变化风险，带来收益不够明显，所以定长字符串使用 意义有限。

3.6. 枚举类型

包括 Enum8 和 Enum16 类型。Enum 保存 'string'= integer 的对应关系。

Enum8 用 'String'= Int8 对描述。
Enum16 用 'String'= Int16 对描述。

CREATE TABLE t_enum
(
   x Enum8('hello' = 1, 'world' = 2)
)
ENGINE = TinyLog;

-- 此时存储可以使用key存储，也可以使用value进行存储。select时，默认显示key，可以使用Cast(colName, toTypeName(value))显示value值。

使用场景：对一些状态、类型的字段算是一种空间优化，也算是一种数据约束。但是实际使用中往往因为一些数据内容的变化增加一定的维护成本，甚至是数据丢失问题。所以谨慎使用。

3.7. 时间类型

目前 ClickHouse 有三种时间类型

Date接受年-月-日的字符串比如‘2019-12-16’
Datetime 接受年-月-日 时:分:秒的字符串比如 ‘2019-12-16 20:50:10’
Datetime64 接受年-月-日 时:分:秒.亚秒的字符串比如‘2019-12-16 20:50:10.66’

日期类型，用两个字节存储，表示从 1970-01-01 (无符号) 到当前的日期值。

3.8. 数组

Array(T):由 T 类型元素组成的数组。

T 可以是任意类型，包含数组类型。 但不推荐使用多维数组，ClickHouse 对多维数组的支持有限。例如，不能在 MergeTree 表中存储多维数组。

创建数组的方式：
Array(1,2)
[1,2]

4. 表引擎

4.1. TinyLog

不支持索引，没有并发控制。一般保存少量数据的小表， 生产环境上作用有限。

create table t_tinylog (id String, name String) engine=TinyLog;

4.2. Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。

4.3. MergeTree

支持索引和分区。

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
    ...
    INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
    INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
) ENGINE = MergeTree()
ORDER BY expr
[PARTITION BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
[SETTINGS name=value, ...]

PARTITION BY分区

降低扫描的范围，优化查询速度。

可选项，如果不选默认使用一个all分区。

分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。

数据写入与分区合并：任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入后的某个时刻(大概 10-15 分钟后)，ClickHouse 会自动执行合并操作(等不及也可以手动通过 optimize 执行)，把临时分区的数据，合并到已有分区中。

OPTIMIZE TABLE table_name PARTITION partition_name FINAL;

透过自带的client查询的时候，数据会显示分区的详情，透过其他工具则不会有。

数据在分区内有序。

PRIMARY KEY主键

ClickHouse中的主键只有一级索引，并没有唯一性约束。

在where语句中根据主键查询信息，会对主键进行某种形式的二分查找，从而定位到index granularity信息，避免全盘扫描。

index granularity:索引粒度，指在稀疏索引中两个相邻索引对应数据的间隔。ClickHouse 中的 MergeTree 默认是 8192。

要求：主键必须是 order by 字段的前缀字段。

ORDER BY 排序字段【必选】

此字段设定了分区内的数据按照哪些字段顺序进行有序保存，是 MergeTree 中唯一一个必填项。

二级索引

INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1

GRANULARITY value1 是设定二级索引对于一级索引粒度的粒度。

create table t_order_mt2(
   id UInt32,
sku_id String,
total_amount Decimal(16,2), create_time Datetime,
    INDEX a total_amount TYPE minmax GRANULARITY 5
 ) engine =MergeTree
  partition by toYYYYMMDD(create_time)
  primary key (id)
    order by (id, sku_id);

TTL

TTL 即 Time To Live，MergeTree 提供了可以管理数据表或者列的生命周期的功能。

列级别TTL
name1 [type1] [TTL expr1],

create table t_order_mt3(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2) TTL create_time+interval 10 SECOND, 
   create_time Datetime
 ) engine =MergeTree
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id, sku_id);

 -- total_amount Decimal(16,2) TTL create_time+interval 10 SECOND, 
 -- 在create_time时间的10秒之后total_amount字段变成默认值

需要合并后才会看到效果。

表级别TTL
alter table table_name MODIFY TTL create_time + INTERVAL 10 SECOND;
-- 表数据会在 create_time 之后 10 秒消失。

涉及判断的字段必须是 Date 或者 Datetime 类型，推荐使用分区的日期字段。

4.4. ReplacingMergeTree

存储特性完全继承 MergeTree，只是 多了一个去重的功能。

会根据order by字段去重，并不是根据primary key字段去重。

去重的过程只会在合并的过程中出现，合并会在后台不定时进行，无法进行预知，所以有些数据可能还未被处理。

如果表经过了分区，则只会在分区内进行去重。

适用于在后台清理重复的数据以节省空间，不能保证没有重复的数据出现。

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
    ...
) ENGINE = ReplacingMergeTree([ver])
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]

ENGINE = ReplacingMergeTree([ver])填入的为版本字段，重复的数据保留版本值最大的。

如果不填ver或者ver相同，则默认按照插入顺序保留最后一条。

4.5. SummingMergeTree

对于不查询明细，只关心以维度进行汇总聚合结果的场景。如果只使用普通的 MergeTree 的话，无论是存储空间的开销，还是查询时临时聚合的开销都比较大。

ClickHouse 为了这种场景，提供了一种能够“预聚合”的引擎 SummingMergeTree。

create table t_order_smt(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2) ,
   create_time Datetime
) engine =SummingMergeTree(total_amount)
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id );

engine =SummingMergeTree(total_amount)中，total_amount列作为汇总数据列。

可以填写多列必须数字列，如果不填，以所有非维度列且为数字列的字段为汇总数据列。

以 order by 的列为准，作为维度列。

其他的列按照插入的顺序保留最开始插入的一行。

聚合只会聚合同一个分区内的数据。

只有在同一个批次插入或者分片合并的时候才会进行聚合。如果要是获取汇总值，还是需要使用 sum 进行聚合。

5. SQL

SQL语法

5.1. Insert

-- 插入字段
insert into [table_name] values(...),(....);
-- 插入表
insert into [table_name] select a,b,c from [table_name_2];

5.2. Alter

Delete和Update都是Alter的一种。这类被称作可变查询(Mutation 查询)。

Mutation 查询是一种很重的操作（每次修改或者删除都会导致放弃目标数据的原有分区，重建新分区），而且不支持事务。应该尽量做批量变更，不要作频繁的小数据操作。

ALTER TABLE [db].name ADD INDEX name expression TYPE type GRANULARITY value [FIRST|AFTER name] - 向表元数据添加索引描述。

ALTER TABLE [db].name DROP INDEX name - 从表元数据中删除索引描述并从磁盘中删除索引文件。

-- 前两个命令是轻量级的，它们只更改元数据或删除文件。

ALTER TABLE [db.]table MATERIALIZE INDEX name IN PARTITION partition_name - 查询在分区partition_name中重建二级索引name。 操作为mutation.

ALTER TABLE [db].name DELETE WHERE column_name = value;

ALTER TABLE [db].name UPDATE column_name1 = value1 WHERE column_name2 = value2;

alter table tableName add column newcolname String after col1;

alter table tableName modify column colname String;

alter table tableName drop column colname;

实现高性能update或delete的思路：

create table  A
(
  a xxx,
  b xxx,
  c xxx,
  _sign UInt8,
  _version UInt32
)

==> 更新 ： 插入一条新的数据， _version + 1 =》 查询的时候加上一个过滤条件， where version最大

==> 删除： _sign, 0表示未删除，1表示已删除， 同时 version + 1 =》 查询的时候加上一个过滤条件， where _sign=0 and version最大

==> 时间久了，数据膨胀 ==》 类似合并机制，怎么把过期数据清除掉

5.3. 查询

  • 支持子查询

  • 支持 CTE(Common Table Expression 公用表表达式 with 子句)

  • 支持各种JOIN，但是JOIN操作无法使用缓存，所以即使是两次相同的JOIN语句，

    ClickHouse 也会视为两条新 SQL（少用）

  • 窗口函数(官方正在测试中...)

  • 不支持自定义函数

  • GROUP BY 操作增加了 with rollup\with cube\with total 用来计算小计和总计。

    with rollup\with cube\with total

维度是a,b
rollup：上卷  从右至左去掉维度进行小计
      group by a,b 
      group by a 
      空
cube：多维分析 从右至左去掉维度进行小计，再从左至右去掉维度进行小计
      group by  a,b 
      group by  a
      group by  b 
      空
total：总计  只计算合计
      group by  a,b 
      空

    select id , sku_id,sum(total_amount) from t_order_mt group by id,sku_id with rollup;

select id , sku_id,sum(total_amount) from t_order_mt group by id,sku_id with cube;

select id , sku_id,sum(total_amount) from t_order_mt group by id,sku_id with totals;

5.4. 函数

函数

条件函数

5.5. 导出数据

clickhouse-client --query "select * from t_order_mt where
create_time='2020-06-01 12:00:00'" --format CSVWithNames>
/opt/module/data/rs1.csv

更多格式参照：输入/输出格式

6. EXPLAIN

仅支持20.6以上版本。

  1. 查看 PLAIN（默认）

    explain plan select arrayJoin([1,2,3,null,null]);

explain select database,table,count(1) cnt from system.parts where database in ('datasets','system') group by database,table order by database,cnt desc limit 2 by database;

-- 打开全部的参数的执行计划
EXPLAIN header=1, actions=1,description=1 SELECT number from
system.numbers limit 10;

  2. AST树

    EXPLAIN AST SELECT number from system.numbers limit 10;

  3. SYNTAX语法优化（常用）

    -- 开启三元运算符优化
SET optimize_if_chain_to_multiif = 1;

-- EXPLAIN SYNTAX + SQL
EXPLAIN SYNTAX SELECT number = 1 ? 'hello' : (number = 2 ? 'world' : '2021') FROM numbers(10);
//返回优化后的语句
SELECT multiIf(number = 1, \'hello\', number = 2, \'world\', \'2021\') FROM numbers(10)

  4. 查看PIPELINE（线程情况）

    ```sql EXPLAIN PIPELINE SELECT sum(number) FROM numbers_mt(100000) GROUP BY number % 20;

-- 打开其他参数 EXPLAIN PIPELINE header=1,graph=1 SELECT sum(number) FROM numbers_mt(10000) GROUP BY number%20;


### 老版本查看执行计划

```sql
clickhouse-client -h 主机名 --send_logs_level=trace <<< "SQL语句" > /dev/null

其中，send_logs_level 参数指定日志等级为 trace，<<<将 SQL 语句重定向至 clickhouse-client 进行查询，> /dev/null 将查询结果重定向到空设备吞掉，以便观察日志。

7. 副本

副本的目的主要是保障数据的高可用性，即使一台 ClickHouse 节点宕机，那么也可以从 其他服务器获得相同的数据。

副本只支持合并树家族引擎，且只针对表。

create table t_order_rep2 (
   id UInt32,
sku_id String,
total_amount Decimal(16,2), create_time Datetime
 ) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id);

CK采用的是多主模式，即没有主从之分。随意的一个节点修改另一个节点也会进行同步。

7.1. 步骤

  1. 启动ZooKeeper服务

  2. 在CK中添加ZK的配置

    有两种方式：

    1. 在原有的配置文件中进行配置

      config.xml

      <?xml version="1.0"?>
<yandex>
    <zookeeper-servers>
       <node index="1">
<host>hadoop102</host>
           <port>2181</port>
       </node>
       <node index="2">
           <host>hadoop103</host>
           <port>2181</port>
       </node>
       <node index="3">
           <host>hadoop104</host>
           <port>2181</port>
       </node>
    </zookeeper-servers>
</yandex>

    2. 在外部配置文件中配置后在原有的配置中进行导入

      config.d/metrika.xml:

      <?xml version="1.0"?>
<yandex>
    <zookeeper-servers>
       <node index="1">
<host>hadoop102</host>
           <port>2181</port>
       </node>
       <node index="2">
           <host>hadoop103</host>
           <port>2181</port>
       </node>
       <node index="3">
           <host>hadoop104</host>
           <port>2181</port>
       </node>
    </zookeeper-servers>
</yandex>

      config.xml

      <include_from>/etc/clickhouse-server/config.d/metrika.xml</include_from>

<!-- 外部导入需要添加下面的属性 -->
<zookeeper incl="zookeeper-servers" optional="true" />

    3. 将上述修改同步到多个主机上，并重启ZK和CK。

    4. 副本只同步表内容，表需要进行分别创建。

      create table t_order_rep2 (
   id UInt32,
sku_id String,
total_amount Decimal(16,2), create_time Datetime
 ) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id);

      其中，ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')

      第一个参数是分片的zk_path一般按照:/clickhouse/table/{shard}/{table_name} 的格式写，如果只有一个分片就写 01 即可。

      第二个参数是副本名称，相同的分片副本名称不能相同，所以在不同的节点上都应该不同。

8. 分片集群

副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决。

要解决数据水平切分的问题，需要引入分片的概念。通过分片把一份完整的数据进行切分，不同的分片分布到不同的节点上，再通过 Distributed 表引擎把数据拼接起来一同使用。

Distributed 表引擎本身不存储数据，通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据。

ClickHouse 的集群是表级别的，实际企业中，大部分做了高可用，但是没有用分片，避免降低查询性能以及操作集群的复杂性。

8.1. 集群写入和读取流程流程（3分片2副本为例）

image-20211212161735369
Image
image-20211212161746975
Image

8.2. 配置步骤

有两种方式，内部配置和上面副本的内部配置相似。

  1. config.d/metrika.xml

    <remote_servers> 
  <!-- 集群名称，可以自己设置 -->  
  <gmall_cluster> 
    <!--集群的第一个分片-->  
    <shard> 
      <internal_replication>true</internal_replication>
      <!--该分片的第一个副本-->  
      <replica> 
        <host>hadoop102</host>  
        <port>9000</port> 
      </replica>
      <!--该分片的第二个副本-->  
      <replica> 
        <host>hadoop103</host>  
        <port>9000</port> 
      </replica> 
    </shard>
    <!--集群的第二个分片-->  
    <shard> 
      <internal_replication>true</internal_replication>  
      <!--该分片的第一个副本-->
      <replica> 
        <host>hadoop104</host>  
        <port>9000</port> 
      </replica> 
    </shard> 
  </gmall_cluster> 
</remote_servers>

<zookeeper-servers> 
  <node index="1"> 
    <host>hadoop102</host>  
    <port>2181</port> 
  </node>  
  <node index="2"> 
    <host>hadoop103</host>  
    <port>2181</port> 
  </node>  
  <node index="3"> 
    <host>hadoop104</host>  
    <port>2181</port> 
  </node> 
</zookeeper-servers>

<!-- 宏指令 -->
<macros> 
  <!-- 存放的分片数 不同机器放的分片数不一样-->
  <shard>01</shard>
  <!--不同机器放的副本数不一样--> 
  <!-- rep_1_1 副本名 = 名字_分片数_副本数 -->
  <replica>rep_1_1</replica>  
</macros>

  2. config.xml

    <include_from>/etc/clickhouse-server/config.d/metrika.xml</include_from>

<!-- 外部导入需要添加下面的属性 -->
<zookeeper incl="zookeeper-servers" optional="true" />

  3. 同步上述两个文件到其他机器并修改macros中的参数，然后重启全部CK。

  4. 在集群上创建本地表

    create table st_order_mt on cluster gmall_cluster (    -- gmall_cluster为配置文件中指定的集群名字
  id UInt32,
    sku_id String,
    total_amount Decimal(16,2), create_time Datetime
 ) engine
=ReplicatedMergeTree('/clickhouse/tables/{shard}/st_order_mt','{replica}')    -- 此处引擎要用分布式的合并树家族的引擎之一，(zk_path){shard}和(副本名){replica}会自动读取<macros>中的变量。st_order_mt此处和创建的表名一致
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id,sku_id);

  5. 创建分布式表

    create table st_order_mt_all2 on cluster gmall_cluster    -- -- gmall_cluster为配置文件中指定的集群名字
(
    id UInt32, 
  sku_id String,
    total_amount Decimal(16,2), create_time Datetime
)engine = Distributed(gmall_cluster,default, st_order_mt,hiveHash(sku_id));

    Distributed(集群名称，库名，本地表名，分片键);

  6. 使用分布式表进行数据操作

    insert into st_order_mt_all2 values
(201,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(202,'sku_002',2000.00,'2020-06-01 12:00:00'),
(203,'sku_004',2500.00,'2020-06-01 12:00:00'),
(204,'sku_002',2000.00,'2020-06-01 12:00:00'),
(205,'sku_003',600.00,'2020-06-02 12:00:00');

  7. 查询的时候使用分布式表

    SELECT * FROM st_order_mt_all;

    注意：

    查询本地表只会查询到本机存储部分的信息。

    查询到的结果会分区、分片显示(clickhouse-client)。

    相同分片下的不同副本存储的信息相同。

    不同分片存储的信息不同。

9. 优化

9.1. 表优化

  1. 时间字段的类型

    建表时能用数值型或日期时间型表示的字段就不要用字符串。

    ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型， 因为 DateTime 不需要经过函数转换处理，执行效率高、可读性好。

  2. 空值存储类型

    Nullable类型几乎总是会拖累性能，因为存储Nullable列时需要创建一个 额外的文件(column_name.null.bin)来存储 NULL 的标记，并且 Nullable 列无法被索引。

    除非极特殊情况，应直 接使用字段默认值表示空，或者自行指定一个在业务中无意义的值(例如用-1 表示没有商品 ID)。

  3. 分区和索引

    一般选择按天分区，也可以指定为 Tuple()， 以单表一亿数据为例，分区大小控制在 10-30 个为最佳。

    必须指定索引列，ClickHouse 中的索引列即排序列，通过 order by 指定。

    通常需要满足高级列在前、查询频率大的在前原则。

    基数特别大的不适合做索引列， 如用户表的 userid 字段;通常筛选后的数据满足在百万以内为最佳。

    PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))

PARTITION BY toYYYYMM(StartDate)
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)

  4. 表参数

    Index_granularity 是用来控制索引粒度的，默认是 8192，如非必须不建议调整。

    如果表中不是必须保留全量历史数据，建议指定 TTL(生存时间值)，可以免去手动过期历史数据的麻烦，TTL 也可以通过 alter table 语句随时修改。

  5. 写入和删除优化

    1. 尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台 Merge 任务带来巨大压力。

    2. 不要一次写入太多分区，或数据写入太快，数据写入太快会导致 Merge 速度跟不上而报错，一般建议每秒钟发起 2-3 次写入操作，每次操作写入 2w~5w 条数据(依服务器性能而定

      写入过快报错，报错信息：

      1. Code: 252, e.displayText() = DB::Exception: Too many parts(304).
Merges are processing significantly slower than inserts
2. Code: 241, e.displayText() = DB::Exception: Memory limit (for query)
exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888
bytes), maximum: 9.31 GiB

      处理方式： “ Too many parts 处理 ” :使用 WAL 预写日志，提高写入性能。in_memory_parts_enable_wal 默认为 true

      在服务器内存充裕的情况下增加内存配额，一般通过 max_memory_usage 来实现在服务器内存不充裕的情况下，建议将超出部分内容分配到系统硬盘上，但会降低执行速度，一般通过 max_bytes_before_external_group_by、max_bytes_before_external_sort 参数来实现。

9.2. 配置优化

配置项主要在 config.xml 或 users.xml 中， 基本上都在 users.xml 里。

config.xml的配置项

users.xml的配置项

CPU资源

配置 描述
background_pool_size 后台线程池的大小，merge 线程就是在该线程池中执行，该线程池不仅仅是给 merge 线程用的，默认值 16，允许的前提下建议改成 c pu 个数的 2 倍(线程数)。
background_schedule_pool_size 执行后台任务(复制表、Kafka 流、DNS 缓存更新)的线程数。默 认 128，建议改成 cpu 个数的 2 倍(线程数)。
backgrounddistributed_schedule pool_size 设置为分布式发送执行后台任务的线程数，默认 16，建议改成 cpu 个数的 2 倍(线程数)。
max_concurrent_queries 最大并发处理的请求数(包含 select,insert 等)，默认值 100，推荐 150(不够再加)~300。
max_threads 设置单个查询所能使用的最大 cpu 个数，默认是 cpu 核数。

内存资源

配置 描述
max_memory_usage 此参数在 users.xml 中,表示单次 Query 占用内存最大值，该值可 以设置的比较大，这样可以提升集群查询的上限。 保留一点给 OS，比如 128G 内存的机器，设置为 100GB。
maxbytes_before_external_group by 一般按照 max_memory_usage 的一半设置内存，当 group 使用内 存超过阈值后会刷新到磁盘进行。 因为 clickhouse 聚合分两个阶段:查询并及建立中间数据、合并中间数据，结合上一项，建议 50GB。
max_bytes_before_external_sort 当 order by 已使用 max_bytes_before_external_sort 内存就进行 溢写磁盘(基于磁盘排序)，如果不设置该值，那么当内存不够时直接 抛错，设置了该值 order by 可以正常完成，但是速度相对存内存来 说肯定要慢点(实测慢的非常多，无法接受)。
max_table_size_to_drop 此参数在 config.xml 中，应用于需要删除表或分区的情况，默认是 50GB，意思是如果删除 50GB 以上的分区表会失败。建议修改为 0， 这样不管多大的分区表都可以删除。

存储

ClickHouse 不支持设置多数据目录，为了提升数据 IO 性能，可以挂载虚拟卷组，一个卷组绑定多块物理磁盘提升读写性能。

9.3. 语法优化

  1. count函数优化

    如果使用的是 count() 或者 count(*)，且没有 where 条件，则会直接使用 system.tables 的 total_rows（counts.txt）

    如果 count 具体的列字段，则不会使用此项优化。

  2. 消除子查询重复字段

    表的字段相同，比如select a, a会被优化成select a。

    也会删除重复的order by key，limit by key, using key，只要判断是同一个表中的同一个字段就会被优化，即使用了别名也没用。

  3. 谓词下推

    当 group by 有 having 子句，但是没有 with cube、with rollup 或者 with totals 修饰的时候，having 过滤会下推到 where 提前过滤。例如下面的查询，HAVING name 变成了WHERE name，在 group by 之前过滤。子查询也支持谓词下推。

    EXPLAIN SYNTAX 
    SELECT UserID 
    FROM hits_v1 
    GROUP BY UserID 
    HAVING UserID = '8585742290196126178';

-- 返回优化语句
SELECT UserID
FROM hits_v1
WHERE UserID = \'8585742290196126178\' GROUP BY UserID

    EXPLAIN SYNTAX SELECT
* 
FROM
    ( SELECT * FROM ( SELECT UserID FROM visits_v1 ) UNION ALL SELECT * FROM ( SELECT UserID FROM visits_v1 ) ) 
WHERE
    UserID = '8585742290196126178'

-- 返回优化语句
SELECT
    UserID 
FROM
    (
    SELECT
        UserID 
    FROM
        (
        SELECT
            UserID 
        FROM
            visits_v1 
        WHERE
            UserID = \ '8585742290196126178\'
            )
            WHERE UserID = \'8585742290196126178\'
            UNION ALL
            SELECT UserID
            FROM
            (
            SELECT UserID
            FROM visits_v1
            WHERE UserID = \'8585742290196126178\'
            )
            WHERE UserID = \'8585742290196126178\'
        )
    WHERE UserID = \'8585742290196126178\'

  4. 聚合计算外推

    sum(a * 2)会被优化成sum(a) * 2

  5. 聚合函数消除

    EXPLAIN SYNTAX
SELECT
   sum(UserID * 2),
   max(VisitID),
   max(UserID)
FROM visits_v1
GROUP BY UserID

-- 返回优化语句
SELECT
   sum(UserID) * 2,
   max(VisitID),
     UserID    -- 此时max(UserID)无意义，被优化
FROM visits_v1
GROUP BY UserID

  6. 标量替换

    如果子查询只返回一行数据，在被引用的时候用标量替换。

  7. 三元运算优化

    如果开启了 optimize_if_chain_to_multiif 参数，三元运算符会被替换成 multiIf 函数。

9.4. 查询优化

单表查询

  1. PREWHERE替代WHERE

    Prewhere 和 where 语句的作用相同，用来过滤数据。不同之处在于 prewhere 只支持 *MergeTree 族系列引擎的表。

    Prewhere会读取指定的列数据，按照条件进行过滤后再读取select需要的列字段进行其他属性的补全。

    当查询列明显多于筛选列时使用 Prewhere可十倍提升查询性能，Prewhere 会自动优化执行过滤阶段的数据读取方式，降低 io 操作。

    在某些场合下，prewhere 语句比 where 语句处理的数据量更少性能更高。

    -- 开关where自动转where（默认开）
set optimize_move_to_prewhere=0;    -- 关
set optimize_move_to_prewhere=0;    -- 开

    默认情况，我们不会关闭 where 自动优化成 prewhere。

    但是某些场景即使开启优化，也不会自动转换成 prewhere，需要手动指定 prewhere（即把where关键字换成prewhere即可）。

    不会自动转换成prewhere的情况：

    1. 使用常量表达式
    2. 默认值为alias类型的字段
    3. 包含了arrayJOIN、globalIn、globalNotIn或者indexHint的查询
    4. select查询的列字段和where的谓词相同
    5. 使用了主键字段

  2. 数据采样

    SELECT Title,count(*) AS PageViews
FROM hits_v1
SAMPLE 0.1 #代表采样 10%的数据,也可以是具体的条数 WHERE CounterID =57
GROUP BY Title
ORDER BY PageViews DESC LIMIT 1000

    采样修饰符只有在 MergeTree engine 表中才有效，且在创建表时需要指定采样策略。

  3. 列裁剪和分区裁剪

    1. 数据量太大时应避免使用 select * 操作（宽表），字段越少，消耗的 io 资源越少，性能就会越高。
    2. 分区裁剪就是只读取需要的分区，在过滤条件中指定。where EventDate='2014-03-23';

  4. orderby 结合 where、limit

    避免全表排序，可能会导致资源不足或者检索过长。千万以上数据集进行 order by 查询时需要搭配 where 条件和 limit 语句一起使用。

    SELECT UserID,Age
FROM hits_v1
ORDER BY Age DESC LIMIT 1000

  5. 避免构建虚列，可以在前端进行处理或者在表中构造实际字段进行额外存储。

  6. uniqCombined 替代 distinct

    性能可提升 10 倍以上，uniqCombined 底层采用类似 HyperLogLog 算法实现，能接收 2% 左右的数据误差（对误差要求比较严格的还是用distinct），可直接使用这种去重方式提升查询性能。Count(distinct)会使用 uniqExact 精确去重。

    不建议在千万级不同数据上执行 distinct 去重查询，改为近似去重 uniqCombined。

  7. 使用物化视图

  8. 其他注意事项

    1. 查询熔断 为了避免因个别慢查询引起的服务雪崩的问题，除了可以为单个查询设置超时以外，还 可以配置周期熔断，在一个查询周期内，如果用户频繁进行慢查询操作超出规定阈值后将无 法继续进行查询操作。

    2. 关闭虚拟内存

      物理内存和虚拟内存的数据交换，会导致查询变慢，资源允许的情况下关闭虚拟内存。

    3. 配置 join_use_nulls 为每一个账户添加 join_use_nulls 配置，左表中的一条记录在右表中不存在，右表的相 应字段会返回该字段相应数据类型的默认值，而不是标准 SQL 中的 Null 值。

    4. 批量写入时先排序

      批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对 需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致 ClickHouse 无法及时对 新导入的数据进行合并，从而影响查询性能。

    5. 关注 CPU cpu 一般在 50%左右会出现查询波动，达到 70%会出现大范围的查询超时，cpu 是最关 键的指标，要非常关注。

多表关联

多表关联应该尽量减少使用join，CK的join原理：将右表加载到内存，再和左表进行匹配。

  1. 如果语句能够使用in替换，则使用in。

  2. 满足小表在右的原则（这里和MySQL相反），减小内存的使用。

  3. 限制条件尽量往上提，能先过滤先过滤，减小数据的比较。（谓词下推）

    这里有个小点，having是根据结果进行过滤，可以考虑能否用where替代（先过滤再进行比较），进而可以再考虑是否可以使用prewhere（读取指定的列数据，按照条件进行过滤后再读取select需要的列字段进行其他属性的补全）。

  4. 使用字典表

  5. 分布式表中要使用GLOBAL关键字

    两张分布式表上的 IN 和 JOIN 之前必须加上 GLOBAL 关键字，右表只会在接收查询请求的那个节点查询一次，并将其分发到其他节点上。如果不加 GLOBAL 关键字的话，每个节点都会单独发起一次对右表的查询，而右表又是分布式表，就导致右表一共会被查询 N2(N 是该分布式表的分片数量)，这就是查询放大，会带来很大开销。

10. 数据一致性

注意点：ReplacingMergeTree不能保证数据一定没有重复（未merge等情况），只能保证数据的最终一致性。

保持数据一致性的解决方案：

  1. 手动去重

    OPTIMIZE TABLE table_name PARTITION partition_name FINAL;

    生产环境不推荐。

  2. 使用SQL实现去重（加标记字段）

    -- create_time 是版本号字段，每组数据中 create_time 最大的一行表示最新的数据; deleted 是自 定的一个标记位，比如 0 代表未删除，1 代表删除数据。

SELECT
    user_id ,
  argMax(score, create_time) AS score,
  argMax(deleted, create_time) AS deleted,
  max(create_time) AS ctime
FROM test_a
GROUP BY user_id
HAVING deleted = 0;

-- argMax(field1，field2):按照 field2 的最大值取 field1 的值。
-- 当我们更新数据时，会写入一行新的数据，例如上面语句中，通过查询最大的create_time 得到修改后的 score 字段值。

CREATE VIEW view_test_a AS
SELECT
  user_id ,
  argMax(score, create_time) AS score,
  argMax(deleted, create_time) AS deleted,
  max(create_time) AS ctime
FROM test_a
GROUP BY user_id
HAVING deleted = 0;

SELECT *
FROM view_test_a WHERE user_id = 0;

-- 透过创建视图，可以将筛选的操作保存起来。

    在这种情况下，进行删除或者更新，本质上还是进行数据的插入。最终透过条件筛选得出最新的未被标记为删除的数据。

    数据并没有被真正的删除，而是被过滤掉了。在一些合适的场景下，可以结合表级别的 TTL 最终将物理数据删除。

  3. 使用FINAL。

    老版本的FINAL是单线程。

    新版本的FINAL是多线程，但是读取part的过程是串行的。

    SELECT * FROM visits_v1 FINAL WHERE StartDate = '2014-03-17' LIMIT 100

  4. 对数据重复要求比较低，并且数据误差不大，不管。

11. 物化视图

物化视图和普通视图的区别：普通视图不保存数据，保存的仅仅是查询语句。物化视图则是把查询的结果根据相应的引擎存入到了磁盘 或内存中。

优点：查询速度快，要是把物化视图这些规则全部写好，它比原数据查询快了很多，总的行数少了，因为都预计算好了。

缺点：1. 它的本质是一个流式数据的使用场景，是累加式的技术，所以要用历史数据做去重、去核这样的分析，在物化视图里面是不太好用的。在某些场景的使用也是有限的。而且 如果一张表加了好多物化视图，在写这张表的时候，就会消耗很多机器的资源，比如数据带宽占满、存储一下子增加了很多。2. 物化视图的 alter 操作有些限制，操作起来不大方便。3. 物化视图的 alter 操作有些限制，操作起来不大方便。物化视图不支持同步删除，若源表的数据不存在(删除了)则物化视图的数据仍然保留。

11.1. 语法

CREATE [MATERIALIZED] VIEW [IF NOT EXISTS]    -- 视图名
[db.]table_name    -- 原表
-- 1. 默认创建一个隐藏的目标表( .inner.物化视图名)来保存视图数据。使用 TO 表名，保存到一张显式的表。
-- 2. 若物化视图的定义使用了 TO [db.]name 子语句，则可以将目标表的视图卸载DETACH 再装载 ATTACH
[TO[db.]name]    
[ENGINE = engine]    -- 必须指定物化视图的 engine 用于数据存储
[POPULATE]    -- 是否带入历史数据（不推荐），需要历史数据自己进行insert即可。且TO [db].[table]语法的时候，不得使用 POPULATE。
    AS 
    SELECT ...



#建表语句
CREATE MATERIALIZED VIEW hits_mv
ENGINE=SummingMergeTree
PARTITION BY toYYYYMM(EventDate) 
ORDER BY (EventDate, intHash32(UserID)) 
AS 
    SELECT
    UserID,
    EventDate,
    count(URL) as ClickCount,
    sum(Income) AS IncomeSum
  FROM hits_test
  WHERE EventDate >= '2014-03-20' #设置更新点,该时间点之前的数据可以另外通过
  GROUP BY UserID,EventDate;

-- 导入增量数据只需要在原表进行插入即可。

-- 导入历史数据
INSERT INTO view_name 
SELECT
    ...

物化视图创建好之后，若源表被写入新数据则物化视图也会同步更新。物化视图不支持同步删除，若源表的数据不存在(删除了)则物化视图的数据仍然保留。

POPULATE

若有 POPULATE 则在创建视图的过程会将源表已经存在的数据一并导入。若无 POPULATE 则物化视图在创建之后没有数据，只会在创建只有同步之后写入源表的数据

官方并不推荐使用 POPULATE，因为在创建物化视图的过程中同时写入的数据不能被插入物化视图。

物化视图是一种特殊的数据表，可以用 show tables 查看。

12. 参数聚合函数

12.1. 路径匹配

  • sequenceMatch(pattern)(timestamp, cond1, cond2)匹配1，不匹配0
  • sequenceCount(pattern)(timestamp, cond1, cond2)计数

用法

-- 建表语句
create  table action_log(
    id   UInt16,
    ref_date  DateTime,
    action  String
)engine=MergeTree()
partition by ref_date
order by ref_date;


-- 插入数据
insert into action_log 
values (1,toDateTime('2021-03-19 14:00:00'),'点赞'),
(1,toDateTime('2021-03-19 14:01:00'),'投币'),
(1,toDateTime('2021-03-19 14:02:00'),'分享'),
(1,toDateTime('2021-03-19 14:03:00'),'转发'),
(1,toDateTime('2021-03-19 14:04:00'),'一键三连');


-- 2在1的后面紧挨着
SELECT sequenceMatch('(?1)(?2)')(ref_date , action = '点赞', action = '投币', action = '分享', action = '转发', action = '一键三连') as cnt  FROM action_log 

-- 2在1的后面紧挨着
-- 1和2中间的时间<=60s
SELECT sequenceMatch('(?1)(?t<=60)(?2)')(ref_date , action = '点赞', action = '投币', action = '分享', action = '转发', action = '一键三连') as cnt  FROM action_log 

-- 4在1的后面 中间隔着两个 两个.
SELECT sequenceMatch('(?1)..(?4)')(ref_date, action = '点赞', action = '投币', action = '分享', action = '转发', action = '一键三连')   FROM action_log 

-- 5在1的后面任意个 用.*表示
SELECT sequenceMatch('(?1).*(?5)')(ref_date, action = '点赞', action = '投币', action = '分享', action = '转发', action = '一键三连')   FROM action_log

12.2. windowFunnel

搜索滑动时间窗中的事件链，并计算从链中发生的最大事件数。

该函数采用如下算法：

  • 该函数搜索触发链中的第一个条件并将事件计数器设置为1。 这是滑动窗口启动的时刻。

  • 如果来自链的事件在窗口内顺序发生，则计数器将递增。 如果事件序列中断，则计数器不再增加。

  • 如果数据在不同的完成点具有多个事件链，则该函数将仅输出最长链的大小。

语法

windowFunnel(window, [mode, [mode, ... ]])(timestamp, cond1, cond2, ..., condN)
  • window — 滑动窗户的大小，表示事件链中第一个事件和最后一个事件的最大间隔。 单位取决于timestamp。用表达式来表示则是：timestamp of cond1 <= timestamp of cond2 <= ... <= timestamp of condN <= timestamp of cond1 + window。
  • mode - 这是一个可选的参数，可以设置一个或多个参数。
    • 'strict_deduplication' - 如果事件链中出现相同的条件，则会停止进一步搜索。
    • 'strict_order' - 不允许其他事件的介入。 例如：在A->B->D->C的情况下，它在D停止继续搜索A->B->C，最大事件数为2。
    • 'strict_increase' - 事件链中的时间戳必须严格上升。
  • timestamp — 包含时间戳的列。 数据类型支持： 日期, 日期时间 和其他无符号整数类型（请注意，即使时间戳支持 UInt64 类型，它的值也不能超过Int64最大值，即2^63-1）。
  • cond — 事件链的约束条件。 UInt8 类型。
SELECT 
  level,user_count,conv_rate_percent
FROM (
  SELECT 
    level,
    uniqCombined(user_id) AS user_count,
    neighbor(user_count, -1) AS prev_user_count,
    if (prev_user_count = 0, -1, round(user_count / prev_user_count * 100, 3)) AS conv_rate_percent
  FROM (
    SELECT
      user_id,
      windowFunnel(900)(
        ts_date_time,
        event_type = 'shtLogon',
        event_type = 'shtKkClick' AND column_type = 'homePage',
        event_type = 'shtOpenGoodsDetail',
        event_type = 'shtAddCart',
        event_type = 'shtOrderDone'
      ) AS level
    FROM (
      SELECT ts_date,ts_date_time,event_type,column_type,user_id
      FROM ods.analytics_access_log_all
      WHERE ts_date >= '2020-06-30' AND ts_date <= '2020-07-02'
      AND site_id IN (10266,10022,10339,10030)
    )
    GROUP BY user_id
  )
  WHERE level > 0
  GROUP BY level
  ORDER BY level ASC
);

漏斗分析


CREATE TABLE action
(
    `uid` Int32,
    `event_type` String,
    `time` datetime
)
ENGINE = MergeTree()
PARTITION BY uid
ORDER BY xxHash32(uid)
SAMPLE BY xxHash32(uid)
SETTINGS index_granularity = 8192


insert into action values(1,'浏览','2020-01-02 11:00:00');
insert into action values(1,'点击','2020-01-02 11:10:00');
insert into action values(1,'下单','2020-01-02 11:20:00');
insert into action values(1,'支付','2020-01-02 11:30:00');

insert into action values(2,'下单','2020-01-02 11:00:00');
insert into action values(2,'支付','2020-01-02 11:10:00');

insert into action values(1,'浏览','2020-01-02 11:00:00');

insert into action values(3,'浏览','2020-01-02 11:20:00');
insert into action values(3,'点击','2020-01-02 12:00:00');

insert into action values(4,'浏览','2020-01-02 11:50:00');
insert into action values(4,'点击','2020-01-02 12:00:00');

insert into action values(5,'浏览','2020-01-02 11:50:00');
insert into action values(5,'点击','2020-01-02 12:00:00');
insert into action values(5,'下单','2020-01-02 11:10:00');

insert into action values(6,'浏览','2020-01-02 11:50:00');
insert into action values(6,'点击','2020-01-02 12:00:00');
insert into action values(6,'下单','2020-01-02 12:10:00');






    SELECT 
        user_id,
        windowFunnel(1800)(time, event_type = '浏览', event_type = '点击', event_type = '下单', event_type = '支付') AS level
    FROM 
    (
        SELECT 
            time,
            event_type,
            uid AS user_id
        FROM action
    )
    GROUP BY user_id


    SELECT
        arrayJoin(range(5)) AS level,    -- range(5) = [0,1,2,3,4]
        arraySort(    -- 升序排序
            arrayMap(    -- 将列上的数据转换成数组
                x -> x,
                groupArray(lv)
            )
        ) as arr,    -- 将列转换成数组并升序排序，方便下一层计算
        arrayFilter(    -- 过滤函数
            (x,y) -> x >= y,    -- 筛选条件，如果数字比level大或者等，则表示经过这一个level
            arr,    -- 上面整理好的数组
            arrayWithConstant(    -- level填充，方便上层函数计算。会生成成内容为level，长度为arr的数组。
                LENGTH (arr),
                level
            )
        ) as arr2,    -- 生成了一个通过这一level的数组
        length(arr2) as count    -- 对arr2计数，计算通过这一层的个数（最终结果）。
    FROM
    (
        SELECT 
            user_id,
            windowFunnel(1800)(time, event_type = '浏览', event_type = '点击', event_type = '下单', event_type = '支付') AS lv
        FROM 
        (
            SELECT 
                time,
                event_type,
                uid AS user_id
            FROM action
        )
        GROUP BY user_id
    )

13. 其他

  1. 使用with totals语句后，sum统计行在DataGrip中并没有给出，但在clickhouse-client和DBeaver中都正常显示。应该是DataGrip的锅。

    企业微信截图_16391065389552
    Image
    企业微信截图_1639107407230
    Image

  2. 在查询指定日期的情况下，如果某个日期下没有数据，则这个日期不会显示，解决办法：

    思路：生成一个包含全部时间的表，列如果没有则指定为默认值，然后和原来的表做全连接，最后使用聚合函数配合group by合并即可。

    SELECT t, SUM(metric) as metric FROM (
    SELECT 
        arrayJoin(
          arrayMap( x -> toStartOfHour(addHours(toDateTime($from),x)),
              range(toUInt64(
                  dateDiff('hour', 
                      toDateTime($from), 
                      toDateTime($to)) + 1)))
        ) as t,
        0 as metric

    UNION ALL

    SELECT
        toStartOfHour(my_date) as t,
        COUNT(metric)
        FROM my_table
        WHERE t BETWEEN toDateTime($from) AND toDateTime($to)
        GROUP BY t
)
GROUP BY t ORDER BY t

    https://stackoom.com/question/3OnLU

  3. 跨大版本升级的时候，最好使用SELECT FROM remote的方法。像从20.9.6.14升级到22.2.2.1，bitmap的位数原版本为32，后者为64，会报错Code: 1001. DB::Exception: Received from 192.168.1.1:9000 DB::Exception: std::runtime_error: failed alloc while reading. (STD_EXCEPTION)(vesrion 22.2.2.1)。

    Issue

Copyright © rootwhois.cn 2021-2022 all right reserved，powered by GitbookFile Modify: 2023-03-05 10:55:52

results matching ""

    No results matching ""